REMARKS 



Item (1) on p. 2 of the Office Action states that "Claims 1-57 are pending in this 
application." Applicant notes that claims 12-22 were canceled in Apphcant's previous 
amendment. Claims 1-11 and 23-57 are pending in the application. Reconsideration is 
respectfully requested in light of the following remarks. 

Section 102(e) Rejection ; 

The Examiner rejected claims 1, 2, 4-13 and 15-57 under 35 U.S.C. § 102(e) as 
being anticipated by Lev Ran et al. (U.S. Patent 7,139,811) (hereinafter "Lev Ran"). 
Applicant first notes that claims 12-13 and 15-22 were previously canceled. Thus, this 
rejection is moot in regard to claims 12-13 and 15-22. Applicant respectfully traverses 
this rejection in regard to claims 1, 2, 4-11 and 23-57 for at least the following reasons. 

The Lev Ran reference is directed toward a method for enabling access to a data 
resource which is held on a file server on a first local area network (LAN) by a client on a 
second LAN. A proxy receiver on the second LAN intercepts a request for the data 
resource submitted by the client and transmits a message via a wide area network (WAN) 
to a proxy transmitter on the first LAN, requesting the data resource. The proxy 
transmitter retrieves a replica of the data resource from the file server and conveys the 
replica of the data resource over the WAN to the proxy receiver, which serves the replica 
of the data resource from the proxy receiver to the client over the second LAN. (Lev 
Ran, Abstract). The Lev Ran reference describes a distributed computer system 
comprising two or more geographically-remote LANs interconnected into a WAN. The 
system includes one or more file servers, which are located on respective LANs. The 
Lev Ran reference describes a Virtual File-Sharing Network (VFN) that enables client 
computers on one LAN to efficiently access files held by file servers on other LANs. 
The VFN comprises two or more VFN gateways, each of which is connected to a 
different LAN. The VFN gateways communicate with one another over the 
interconnection provided by the WAN. In order to serve a resource from a file server on 
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a first LAN to a client on a second LAN, the VFN gateway on the first LAN fetches the 
resource from the file server and transmits the resource over the WAN to the VFN 

gateway on the second LAN, which then serves the resource to the client. (Lev Ran, col. 
5, lines 10-27; also see FIG. 1 through FIG. 3). Note in particular that VFN system 20 in 
FIG. 1 and in the description, and VFN gateways 22 in the cited Figures and in the 
description, are clearly distinct fi^om clients 28 and servers (e.g., servers 25, 26, 27, and 
31). 

Regarding claim 1, contrary to the Examiner's assertion, Lev Ran fails to 

teach a remote procedure call system comprising a presentation block configured to 

present data types and Application Programming Interfaces (APIs) available to a 

program on the system. The Examiner cites Lev Ran, col. 56, lines 12-67, Figure 12, 

col. 56, lines 19-25, col. 58, lines 40-67, col. 62, lines 5-16, and col. 56, lines 36-39. In 

particular, the Examiner appears to cite Application Transport Layer 46 as being 

equivalent to a presentation block. In col. 21, lines 21-33, Lev Ran discloses that an 

application transport layer 46: 

...provides services for activation of remote services and inter- VFN 
gateway communication. The remote services are used by adaptation layer 
45 and the higher transmitter and receiver application layers... 

In Col. 56, lines 6-11, Lev Ran further discloses that an application transport layer 

46: 

...is a framework for activating remote services used by the higher VFN 
application layers (adaptation layer 45 and VFN transmitter and receiver 
application layers 42 and 40). The application transport layer provides 
services that enable the different application layers to transfer data to 
and from one another . 

Thus, it is clear that application transport layer 46 is a framework for enabling 
different components internal to VFN gateways 22 to transfer data to and from one 
another. In contrast, the presentation block recited in claim 1 is configured to present 
data types of and APIs to the remote procedure call system to a separate and distinct 
program on the system on which the remote procedure call system is implemented. 
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In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner asserts "it is noted that the features upon which applicant 

relies (i.e., a presentation block configured to present data type and application 
programming interfaces to a separate and distinct program) are not recited in the 
rejected claim(s)...A presentation block configured to present data type and application 
programming interfaces to a separate and distinct program has not been claimed and as 
such was not considered." AppUcant notes that the Examiner should consider the claim 
as a whole. Claim 1 recites a system comprising a processor and a memory comprising 
program instructions executable by the processor to implement a remote procedure call 
system . The remote procedure call system as recited in claim 1 comprises a presentation 
block, an encoding block, a protocol block, and a transport block. The presentation block 
is configured to present data types and Application Programming Interfaces (APIs) 
available to a program on the system . A plain reading of claim 1 makes it clear that "a 
program on the system" is something other than the remote procedure call system itself, 
and is not included in the remote procedure call system, nor is it implemented by the 
program instructions that implement the remote procedure call system, and thus is not 
comprised in or by the remote procedure call system. Applicant's reference to "a 
separate and distinct [from the remote procedure call system] program on the system on 
which the remote procedure call system is implemented" does not require limitations 
from the specification to be read into the claim, as the Examiner wrongly asserts. 
Instead, Applicant is simply arguing the plain meaning of the claims. By stating that the 
remote procedure call system presents data types and APIs to a program , the plain 
meaning of the claim is clear that the program is separate and distinct from the remote 
procedure call system. If one thing presents something to another thing, then they are 
clearly two separate and distinct things. Again, Lev Ran's application transport layer 46 
is not equivalent to a presentation block as recited in claim 1 of the instant application, as 
it is clear from the Lev Ran reference that application transport layer 46 is a framework 
for enabling different components internal to VFN gateways 22 to transfer data to and 
from one another. The "program on the system" recited in Applicant's claim 1 is not 
internal to the remote procedure call system of claim 1 per the plain meaning of the 
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claim. Any other interpretation would not be consistent with the plain wording of the 
claim. 

The Examiner cites Lev Ran, col. 56, lines 19-25, and appears to assert that "RPC 

request messages" are equivalent to "[presenting] data types." The cited reference does 

not teach or suggest that RPC request messages are used to present data types available 

to a program on the system. The Examiner also cites Lev Ran, col. 58, lines 40-67, and 

states "Java object. . .object class or type". It appears to the Apphcant that the Examiner 

is equating "java object. . .object class or type" to "data types". Apphcant notes that col. 

58, lines 40-67 is from a section of the Lev Ran reference titled "Encapsulation", a 

section describing the data encapsulation layer 164, which performs 

serialization/deserialization. Col 58, lines 53-54 disclose that: 

Each object class, or type , preferably has its own serializer and 
deserializer. 

Applicant fails to see how this citation has anything to do with presenting 
data types available to a program on a system. Lev Ran clearly does not teach or 
suggest that the application transport layer 46 presents "java object... object class or 
type" to a program on the system. 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner asserts "As for a remote procedure call system comprising a 
presentation block configured to present data type to a program, page 12 describes the 
presentation block as follows, 'Presentation 100 encompasses the data types that may be 
passed between remote systems...'. The 'java object/object class or type' passed in an 
RPC request/response as disclosed on column 56 lines 20-25 and column 58 lines 40-67 
of the Lev Ran prior art is the data type passed between remote systems as the instant 
specification discloses." As to Lev Ran, col. 56, lines 20-25, the cited reference does not 
teach or suggest that RPC request and RPC response messages are used to present data 
types available to a program on the system . The full paragraph that includes the citation 
reads as follows: 
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Remote services are activated by bidirectionally transferring remote 
procedure call (RFC) messages between a client application transport 
layer ("RFC client") on one VFN gateway and a server application 
transport layer ("RFC server") on a second remote VFN gateway. 
Preferably, the application transport layer functions asymmetrically, 
whereby the RPC client sends RFC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
RPC client . RPC request messages include the request and any necessary 
parameters, and RPC response messages include any necessary return 
values, such as a file. RPC requests, RPC responses, parameters, and 
return values are preferably Java objects, in order to support Java-based 
implementations of the higher application layers. Alternatively, the 
application transport layer functions symmetrically, whereby in addition to 
the RPC client issuing requests to the RPC server, the RPC server can 
issue requests to the RPC client. In such a symmetric implementation, the 
RPC server can connect to the RPC client at a later time in order to 
respond to an earlier request from the RPC client. 

The purpose of the RPC messages as taught by Lev Ran is to "activate remote 
services." In Lev Ran, an RPC client on one VFN gateway and an RPC server on anther 
remote VFN gateway exchange RPC messages to "activate a remote service". Lev Ran 
simply discloses that "RPC requests, RPC responses, parameters, and return values are 
preferably Java objects, in order to support Java-based implementations of the higher 
application layers." The citation does not teach or suggest anything like the notion of a 
presentation block configured to present data types and Application Prosrammins 
Interfaces (APIs) available to a prof^rani on the system . The presentation block as is 
recited in claim 1 has nothing to do with the exchange of RPC messages between a client 
system and a remote server. Indeed, in claim 1 , it is clearly recited that the sending of 
messages to a "remote system" is handled by the transport block of the remote procedure 
call system, and not by the presentation block of the remote procedure call system. The 
presentation block is instead configured to present "data types and APIs" available to a 
program on the system . Furthermore, the "program on the system" in claim 1 is clearly 
and distinctly a different entity than the "remote system" to which "encoded and protocol 
framed outgoing messages" are moved over an interconnect by the transport block . 



As to Lev Ran, col. 58 lines 40-67, Applicant again notes that col. 58, lines 40-67 
is from a section of the Lev Ran reference titled "Encapsulation", a section describing the 
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data encapsulation layer 164 . which performs serialization/deserialization. This 



selection is not even describing Lev Ran's application transport layer 46, but is 
instead describing a different component of Lev Ran's system. In this citation, Lev 

Ran disclose that: 

As mentioned above, RFC parameters are preferably Java objects. Before 
a Java object can be sent to a remote application, it must be converted to 
an XML or binary representation. This conversion is commonly referred 
to as serialization, or "encoding." The XML or binary representation is 
passed to the remote application, which converts it back to the original 
Java object. This conversion back is commonly referred to as 
deseriahzation, or "decoding." RFC client 170 and RFC server 168 use 
serializers to perform encoding, and deserializers to perform decoding. 
Preferably, serializers and deserializers are Java objects that implement 
appropriate Java interfaces, as described below. 

Each object class, or type , preferably has its own serializer and 
deserializer. Data encapsulation layer 164 provides several generic 
serializers and deserializers for common object types, such as String, 
Integer, Float, Boolean, and byte[]. 

Applicant fails to see how this citation dealing with serialization/deserialization 
has anything to do with presenting data types and Application Programming Interfaces 
(APIs) available to a program on a system, as is recited in claim 1 . Lev Ran clearly does 
not teach or suggest that the application transport layer 46 presents "java object... object 
class or type" to a program on the system . Lev Ran instead teaches, in the first cited 
selection, that the application transport layer 46 on a client system and the application 
transport layer 46 on a remote server exchange RFC messages "to activate remote 
services", and that "preferably" Java objects are used in the message exchange "in order 
to support Java-based implementations of the higher application layers." The second 
cited selection, when discussing a different "layer" than the application transport layer 
46, simply describes the serialization/deserialization of "common object types". These 
citations do not teach or suggest anything like a presentation block configured to present 
data types and Application Programming Interfaces (APIs) available to a program on the 
system, as is recited in claim 1 . 
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The Examiner also cites Lev Ran, col. 62, lines 5-16, and quotes from that 
selection ". . .empty RPC request object. . .". It appears to the Applicant that the Examiner 
may be equating "empty RPC request object" to "data types". This citation is from a 
description of FIG. 14, which Lev Ran describes as "a method for processing an RPC 
request by [an] RPC client" (col. 62, lines 5-6). Note that the snipped quote from the 
section comes from a sentence reading in part "The RPC client requests an empty RPC 
request object c..." Applicant fails to see how this citation, in which an RPC cUent is 
described as requesting an empty RPC request object, has anything to do with presenting 
data types available to a program on a system. 

The Examiner also cites Lev Ran, col. 56, lines 36-39, and quotes from that 
selection Application fransport layer 46 ". . .simple API. . .". A more complete context of 
that quote is: 

The application fransport layer provides a simple API to its higher-level clients . . . 

As noted above, it is clear from the Lev Ran reference that application transport 
layer 46 is a framework for enabling different components internal to VFN gateways 22 
to transfer data to and from one another. Remote services are activated by transferring 
remote procedure call (RPC) messages between a cUent application fransport laver ("RPC 
client") on one VFN gateway and a server application fransport layer ("RPC server") on a 
second remote VFN gateway, not to a "program on the system". The higher-level clients 
of Lev Ran's application fransport layer 46 are other layers and components of the VFN 
gateways 22 themselves, and not a "program on the system". In contrast, the 
presentation block recited in claim 1 is configured to present data types and APIs to the 
remote procedure call system to a separate and distinct program on the system on 
which the remote procedure call system is implemented. 

Thus, it is clear from the Lev Ran reference that application fransport layer 46 is a 
framework that exposes interfaces to components of Lev Ran's VFN system internally to 
other components of Lev Ran's VFN system. In confrast, the presentation block recited 
in claim 1 is configured to externally present or expose data types and APIs to the 
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remote procedure call system to a program on the system that is separate and distinct 

from the remote procedure call system. 

In further regard to claim 1, contrary to the Examiner's assertion, Lev Ran 
fails to teach a remote procedure call system comprising a... protocol block configured 
to frame the encodings to denote the intent of the outgoing messages. The Examiner 
cites Lev Ran, col. 61, lines 53-59 in support of this assertion. The Examiner appears to 
equate "RPC protocol manager" with protocol block as disclosed in claim 1 of the instant 
application. The citation provided by the Examiner states that RPC protocol manager 
176: 

...handles network conditions (such as application failures, lost messages, 
out-of-order delivery, and method dependencies) in a generic manner. The 
RPC protocol manager includes, for example, a retransmission mechanism 
on the client side, and a response cache on the server side to aid in 
implementing at-most-once semantics for some requests. 

Applicant can find nothing in the above citation that teaches or suggests 
anything like a protocol block configured to frame the encodings to denote the intent 
of the outsoins messages . Lev Ran's RPC protocol manager "handles network 
conditions"; it is not described as performing any task similar to framfingj the encodings 
to denote the intent of the outgoing messages . The only thing Lev Ran's RPC protocol 
manager 176 as described in the provided citation appears to have in common with the 
protocol block recited in claim 1 is that both include the word "protocol". 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner asserts "the instant application's specification describes the 
protocol block as follows: ' . . .protocol 104 may frame the encoded data with the intent of 
the message... protocol 104 may interpret the intent... For example, response may be 
errors... protocol 104 may handle the error...' page 15 lines 26-29. The RPC Protocol 
Manager 176 of the Lev Ran prior art covers this limitation because it is used for 
determining when an error has occurred during RPC message communication, for 
instance, application failure, lost messages and out-of-order delivery." The Examiner's 
assertion here has nothing to do with what is actually recited in claim 1 of the instant 
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application in regards to the protocol block: a protocol block configured to frame the 
encodings to denote the intent of the outgoing messages. It is improper to rely on 
specific portions of the specification in isolation while ignoring the actual limitations of 
the claim. Again, Lev Ran's RPC protocol manager is described as "handling 
network conditions"; it is not described as performing any task similar to fr am fins] 
the encodings to denote the intent of the outgoing messases, the limtiation that is 
actually recited in claim 1. The only thing Lev Ran's RPC protocol manager 176 as 
described in the provided citation appears to have in common with the protocol 
block recited in claim 1 is that both include the word "protocol". The fact that the 
Examiner can find a selective quotation from Applicant's specification that describes 
"protocol 104" as handling at least some errors does not overcome the fact that Lev Ran's 
"RPC Protocol Manager 176" is nowhere described as being configured to perform 
anything like framing the encodings to denote the intent of the outgoing message as is 
actually recited in claim 1 . The handling of errors by the protocol block is not recited as 
a limitiation in claim 1 of the instant appHcation. The Examiner's assertion that "The 
RPC Protocol Manager 176 of the Lev Ran prior art covers this limitation because it is 
used for determining when an error has occurred during RPC message communication" is 
completely and totally without merit. 

Applicant notes that Application Transport Layer 46 and Adaptation layer(s) 45, 
as well as the other elements illustrated in FIG. 12, are components of VFN transmitter 
52 and VFN receiver 48, which are components of VFN gateways 22, which are in turn 
instantiated on VFN systems 20, which as noted above are clearly distinct from other 
clients and servers in Lev Ran's system (see, for example, FIGs 1 through 3). As noted 
above, the Lev Ran reference describes a Virtual File-Sharing Network (VFN) that 
enables cUent computers on one LAN to access files held by file servers on other LANs. 
The VFN comprises two or more VFN gatewavs . each of which is connected to a 
different LAN . The VFN gateways communicate with one another over the 
interconnection provided by the WAN. In order to serve a resource from a file server on 
a first LAN to a client on a second LAN, the VFN gateway on the first LAN fetches the 
resource from the file server and transmits the resource over the WAN to the VFN 
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gateway on the second LAN, which then serves the resource to the client. In contrast, the 
remote procedure call system recited in claim 1 of the instant application is described as 

being implemented in memory on a system, and as exposing APIs and data types to 
programs on the system . The remote procedure call system is configured to, on behalf of 
a program on the system , encode representations of the data types, frame the encodings, 
and transport the messages from the system to a remote system over an interconnect. 

Applicant reminds the Examiner that anticipation requires the presence in a single 
prior art reference disclosure of each and every element of the claimed invention, 
arranged as in the claim . M.P.E.P 2131; Lindemann Maschinenfabrik GmbH v. 
American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical 
invention must be shown in as complete detail as is contained in the claims. Richardson 
V. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). Nowhere does the Lev Ran 
reference disclose "each and every element of the claimed invention" (claim 1 of the 
instant application) as is arranged in the claim. Indeed, nowhere does the Lev Ran 
reference even disclose the various elements from the reference cited by the Examiner 
arranged in any way resembling the elements of claim 1 of the instant application. For at 
least the reasons given above. Lev Ran clearly does not anticipate Applicant's claim 1. 

Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited art and removal thereof is respectfiiUy requested. Similar remarks 
as those above regarding claim 1 also apply to claims 23, 34, 36 and 47. 

Regarding claim 2, contrary to the Examiner's assertion, Lev Ran fails to 
teach wherein the protocol block is further configured to determine the intent of the 
encoded and protocol framed incoming messages. The Examiner cites Lev Ran, col. 61, 
lines 53-59 in support of this assertion. Again, the Examiner appears to equate "RPC 
protocol manager" with protocol block as disclosed in claim 2 of the instant application. 
Applicant can find nothing in the citation provided by the Examiner that teaches or 
suggests anything like a protocol block configured to determine the intent of the encoded 
and protocol framed incomins messases . Lev Ran's RPC protocol manager "handles 
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network conditions"; it is not described as performing any task similar to determinfing j 
the intent of the encoded and protocol framed incoming messages . 

In further regard to claim 2, contrary to the Examiner's assertion, Lev Ran fails to 

teach wherein the presentation block is further configured to provide the data types from 

the incoming messages to the program on the system. The Examiner cites Lev Ran, col. 

56, lines 16-25 in support of this assertion, and appears to equate "...response 

messages. . ." with "data types from the incoming messages." The context of that snipped 

quote from Lev Ran is: 

Remote services are activated by bidirectionally fransferring remote 
procedure call (RPC) messages between a client application fransport 
layer ("RPC client") on one VPN gateway and a server application 
transport layer ("RPC server") on a second remote VFN gateway. 
Preferably, the application transport layer frinctions asymmetrically, 
whereby the RPC client sends RPC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
RPC client. 

The above citation does not teach or suggest anything like a presentation block 
[that] is... configured to provide the data types from... incoming messages to [a] 
program on the system. In the citation, the RPC response messages are sent from an 
RPC server to an RPC client in response to RPC request messages sent by the RPC client 

to the RPC server. An RPC client is a "client application transport layer... on one VFN 
gateway." Lev Ran further describes the client application transport layer (RPC client) 
beginning at col. 61, line 20. Note that the RPC client is clearly disclosed as a 
component of Lev Ran's VFN system, and not as a program separate from the system. 
The RPC client and RPC server components exchange RPC request and RPC response 
messages internal to Lev Ran's VFN system. Neither one of the components is described 
as providing the data types from incoming messages to a program on the system. 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner again asserts "the 'Java object/object class or type' passed in an 
RPC request/response describes the data type passed between remote systems as the 
instant application discloses." Applicant refers the Examiner to the Applicant's 
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responses to this argument in regards to claim 1. Furthermore, Applicant again notes that 
the RPC response messages are sent from an RPC server to an RPC client in 
response to RPC request messages sent by the RPC client to the RPC server. The 
RPC client and RPC servers are clearly disclosed as components of Lev Ran's VFN 
system, and neither is disclosed as "a program separate from the system". The RPC 
client and RPC server components exchange RPC request and RPC response 
messages internal to Lev Ran's VFN system . Neither one of the components is 
described as providing the data types from incoming messages to a program on the 
system . Furthermore, in claim 2, it is clearly recited that the receiving of messages from 
a "remote system" is handled by the transport block of the remote procedure call system, 
and not by the presentation block of the remote procedure call system. The presentation 
block is instead configured to provide the data types from the incoming messages to the 
program on the system . Furthermore, the "program on the system" in claim 2 is clearly 
and distinctly a different entity than the "remote system" from which incoming messages 
are received by the transport block . 

Thus, for at least the reasons presented above, the rejection of claim 2 is not 
supported by the cited art and removal thereof is respectfiiUy requested. Similar remarks 
as those above regarding claim 2 also apply to claims 26, 35, 39 and 50. 

Applicant also asserts that the rejection of numerous ones of the dependent claims 
is fiirther unsupported by the cited art. However, since the rejection has been shown to 
be unsupported for the independent claims, a fiirther discussion of the dependent claims 
is not necessary at this time. 

Section 103(a) Rejection ; 

The Examiner rejected claims 3 and 14 under 35 U.S.C. § 103(a) as being 
unpatentable over Lev Ran in view of Merrick et al. (U.S. Patent 7,028,312) (hereinafter 
"Merrick"). Applicant first notes that claim 14 was previously canceled. Thus, this 
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rejection is moot in regard to claim 14. Applicant respectfully traverses this rejection in 
regard to claim 3 for at least the following reasons. 

Regarding claim 3, contrary to the Examiner's assertion, the cited art alone or in 

combination fails to teach to determine the intent of the encoded and protocol framed 

incoming messages, the protocol block is further configured to determine if the incoming 

messages are reqeuest messages or response messages. The Examiner notes that Lev 

Ran is silent on to determine the intent of the encoded and protocol framed incoming 

messages, the protocol block is further configured to determine if the incoming messages 

are reqeuest messages or response messages, and asserts that Merrick teaches that 

limitation. In support of that assertion, the Examiner cites Merrick, col. 14, lines 11-14, 

and quotes from that selection "... interprets. . .". That citation states: 

As shown in step 2, the server interprets the request message as a request 
to perform a particular service and performs the service. 

Applicant fails to see how the provided citation from Merrick that teaches a 
server interprets a request message as a request to perforin a particular service is 
supposed to teach or suggest the limitiation of to determine the intent of the encoded and 
protocol framed incoming messages, the protocol block is further configured to 
determine if the incoming messages are reqeuest messages or response messages, as 
recited in claim 3. The citation does not teach or suggest anything along the lines of 
determining if incoming messages are request messages or response messages. Further, 
the provided citation just says a "server" interprets the request message, and mentions 
nothing about a "protocol block" configured to determine the intent of incoming 
messages (e.g., as to whether the incoming messages are request messages or response 
messages). 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner asserts "claim 3 requires a determination as to whether a 
particular message is a request message or response message. The Server of the Merrick 
prior art covers this limitation by fiinctioning to interpret a message as request message 
and performing a particular service as a result of his determination." However, the 
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citation from Merrick does not teacli wliat the Examiner asserts. A more complete 

citation from Merrick (col. 14, lines 4-15) reads: 

FIG. 4 illustrates this process for the case where the transfer protocol is 
one of HTTP, SMTP, or FTP and the messages are transmitted across the 
Internet. According to the XML RPC procedure, and as depicted in step 1 
of the figure, a client uses the transfer protocol to send an XML-based 
message to a server. This message is known as the request message . 
When HTTP is the transfer protocol, it is natural to accomplish this via 
HTTP's POST method. As shown in step 2, the server interprets the 
request message as a request to perform a particular service and performs 
the service. The server may perform this service using information found 
in the request message. 

From the above, it is clear that when the server receives the request message, the 
request message is "known as the request message". Merrick's server does not have to 
determine if the incoming request message is a reqeuest message or a response 
message. Merrick's server would obviously already know that the incoming request 
message is a request message. What Merrick teaches in this citation is that the server 
" interprets the request message [already recognizing the request message as a request 
message, and thus clearly not having to determine if the incoming message is a reqeuest 
message or a response message] as a request to perform a particular service and 
performs the service." In other words, Merricks' server interprets the request message 
as a particular request message to perform a particular service. The Examiner's assertion 
that "The Server of the Merrick prior art covers this limitation by fimctioning to 
interpret a message as request message and performing a particular service as a result 
of his determination" is without merit. The cited art alone or in combination, do not 
teach or suggest anything like a protocol block that is further configured to determine if 
the incoming messages are reqeuest messages or response messages. 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner goes on to assert "As for Merrick prior art not teaching the 
phrase 'protocol block', the test for whether a particular limitation is met is determining 
if the fimctionalities of the claim are met by that of the reference(s) used. In this instance 
the test is not whether the cited references disclose the phrase 'protocol block', but 
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whether they teach the functionality of the claim limitation and the Examiner is 
convinced that the passage used in the rejection cover this limitation. This 

notwithstanding, the fact both request and response messages are disclosed makes it 

inherent that there must be way of differentiating them, otherwise the system would not 

differentiate when it delivering request message from it is delivering a response 

message." The rest of the above citation from Merrick (col. 14, lines 15-19) reads: 

When the service completes, the server generates a reply message . The 
reply message may contain information describing the results of the 
service. In step 3 the server then transmits the reply message to the client 
that initiated the request . 

Merrick's server is described in the cited paragraph and elsehwere as receiving 
request messages and generating and sending reply (response) messages . There would 
be no need in Merrick's described server to determine if the incoming messages are 
reqeuest messages or response messages. As noted above, incoming messages to a 
server in Merrick are request messages. The server generates and sends reply (response) 
messages. The Examiner's assertion that "the fact both request and response messages 
are disclosed makes it inherent that there must be way of differentiating them, otherwise 
the system would not differentiate when it delivering request message from it is 
delivering a response message" is without merit. 

The Examiner goes on to assert that "it would have been obvious... to modify the 

system of Lev Ran with the teaching of Merrick because the teaching of Merrick would 

improve the system of Lev Ran by providing a process for determining the appropriate 

output arguments for a returning responses to a client program", and cites Merrick, col. 

14, lines 34-37. That citation reads as follows: 

The client must also associate reply messages received with request 
messages sent so that it can return the appropriate output arguments from 
the service that the client program invoked. 

Applicant notes that the first citation (Merrick, col. 14, lines 11-14), which refers 
to a server interpreting request messages as requests to perform particular services 
and performing the services [indicated by the request messages], appears to have little if 
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anything to do with the second citation (Merrick, col. 14, lines 34-37), which addresses 
the need for a client to associate received reply messages with sent request messages. In 
other words, the first citation fi-om Merrick does not "provide a process for determining 
the appropriate output arguments for a returning responses to a client program", as the 
Examiner appears to be asserting. 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner asserts "the motivation for combining the Lev Ran and Merrick 
prior arts is drawn from column 14 lines 34-37 of the Merrick prior art. This passage is 
related to the determining step of claim 3 because in determining the type of message, in 
this case a request message, the server then knows the type of response to return to the 
client." The Examiner's argument here is quite confusing, and makes no sense in light of 
the Merrick disclosure. Merrick's server does not have to determine if incoming 
messages are reqeuest messages or response messages. Merrick's server receives 
request messages from Merrick's client and sends reply (response) message to Merrick's 
client. Merrick's server obviously knows that a received reqeust message from a client 
is a request message. There is obviously no need in Merrick for the server to determine 
if the received request message is a request message or a response message. Likewise, 
Merrick's client does not have to determine if incoming messages are reqeuest 
messages or response messages. Merrick's client receives response (reply) messages 
from Merrick's server and sends request messages to Merrick's server. Merrick clearly 
does not teach or even suggest the limitation as recited in claim 3 of the instant 
application. The Examiner asserts "in determining the type of message, in this case a 
request message, the server then knows the type of response to return to the client." 
Merrick's server does not have to determine that an incoming request message is a 
request message. The cited selection from Merrick simply discloses that Merrick's server 
"interprets" a request message to determine what the particular request indicated 
by the request message is, and does not teach or suggest that the server (or the client) 
does anything like determining if incoming messages are reqeuest messages or response 
messages. 
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Merrick, alone or in combination with Lev Ran, does not teach or suggest what 
the Examiner asserts it teaches in regards to claim 3. Furthermore, even if Merrick, 14, 
lines 11-14 did teach what the Examiner asserts it teaches, combining Merrick with Lev 
Ran would not solve the problem that the Examiner asserts it would solve. Furthermore, 
combining the cited references would not produce anything like what is recited in claim 3 
of the instant application. 

Thus, for at least the reasons presented above, the rejection of claim 3 is not 
supported by the cited art and removal thereof is respectfully requested. Applicant again 
notes that claim 14 has been canceled. 
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CONCLUSION 



Applicant respectfully submits that the application is in condition for allowance, 
and prompt notice to that effect is respectfully requested. 



If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
64301/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Apphcant 



Meyertons, Hood, BCivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: July 9. 2007 
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